Positive Bias: the Foundation for High-performance Teams

Hi, friends! 

In these notebook entries, I share a few things that I hope you'll enjoy:

• recent events in the areas of high-performance teams and agile software development
• a curated list of upcoming events
• a request for help to share my class on high-performance teams in your part of the world
• and more

Recent events: positive bias
It seems like everyone has high-performance teams on their mind. Just this morning, I had a great conversation with a young army veteran who had led teams. He said he experienced some incredibly bad teams during his stint in the army. The teams were toxic. They were run by bullying and negativity. His team leaders complained about everything that was the slightest bit wrong. They complained about the army in general, never pointing out anything that was working well for them. They bullied and belittled, barked orders, berated, shamed and embarrassed their people.

In contrast, some of his best teams were the ones that he led himself. He described the experience of learning to be a team leader. At first, he emulated his predecessors: command and control, bullying, shouting, threatening. Then he discovered his true voice. He began to lead with a sense of positivity, a can-do spirit, more like a coach than like a commander. And his teams became excellent. It felt good to be on these teams, and they performed better than other teams.

I use the term positive bias to describe the mindset and behaviors this young leader modeled for his teams. Positive bias is the foundation of high-performance teams. A client company that I'm coaching uses the phrase "assume positive intent" to guide people's interactions with each other. It's the foundation of this company's culture. With positive bias as their foundation, thousands of coworkers support each other and create awesome software together. If positive bias is the only thing you practice together as a team, you'll be better off.

What is the best team you've ever been a member of? What are some examples of positive bias in your best team?

Curated list of upcoming events

• Charles River CoderDojo for kids, Summer 2017 sessions. Register here.
• Agile Software Development, June 19 - July 6 at Harvard University Summer School. Register here.
• Something about Love: Awesome Relationships Fueled by Love, July 16 at Heartspace Teachings in San Jose.
• High-performance Teams: Culture and Core Protocols, half-day Great Teams Academy class preceding Agile2017, August 6 in Orlando. Register here.
• High-performance Teams: Culture and Core Protocols, August 8 at Agile2017 in Orlando. Register here.
• High-performance Teams: Culture and Core Protocols, full-day Great Teams Academy class preceding ALE2017, August 25 in Prague. Register here.
• Agile Software Development, August 28 - December 18 at Harvard University Extension School. Register here.
• Agile Dojo, monthly workshop at Agile New England, September 7.
• High-performance Teams: Culture and Core Protocols, 4-hour session September 28 at GGCon2017 in Paris.
• High-performance Teams: Culture and Core Protocols, October 3 at Agile RTP.

Request for help
I want to share the goodness of high-performance teams in your part of the world. Friends in Europe, I’ll be at ALE2017 in Prague August 25-28. Friends in North America, I’ll be at Agile2017 in Orlando in August, at Agile RTP in October, and around Boston most of the rest of the time.

Want me to visit your part of the world while I’m nearby? Just ask—I’d love to visit and share a class with your team or at your event.

Love,

Richard
With Great People

How to Create More Love

I joined my wife, Molly, and a group of around 25 old and new friends at the Open Space Institute’s conference on Peace and High Performance. I drew this quick sketch of Harrison Owen, creator of Open Space Technology as he reminded us how easy it is to connect using Open Space: just sit in a circle, get a bulletin board, open a marketplace, and it works every time.

My highlight of the conference was a session that Molly and I convened called, “How to create more love”. We've been pondering current events and wondering how to foster more love in the world. A thoughtful group of participants joined the conversation, and we hit upon some important themes:

• Love is both a feeling and an action. It’s a verb. You have to act on it for it to be there. (Harold Shinsato shared this idea, giving credit to Jim McCarthy.)
• It can’t be forced. It’s a gift to offer, not something to smother someone with.

How do you create more love?

Building Great Teams with the Core Protocols, the Tuckman Model, and Google’s Psychological Safety

I’ve been on tour, sharing my Building Great Teams with the Core Protocols class and talk all over North America and in London. And I’m honored and grateful for the positive reviews, reflections, and connections to other people’s work.

Hannes Horn writes about his experience in my half-day class on Medium. He describes the Core Protocols as a way to "speed up the 'Forming to Norming phases of Tuckman’s Team Development Process”. Hannes concludes:

Best of all, taking the Study of Google (The five keys to a successful Google team) the core protocol approach really matters regarding the first key of the study: psychological safety. Developing a team which stops behavior like judging and defending will lead to trust, awareness and openness to each other and that´s the basement of psychological safety.

Peter Antman writes about my one-hour presentation on Crisp’s Blog. He finds utility in the culture-as-a-protocol-stack model that I shared: "I knew about the Core Protocols since before, but clustering them in a stack made it so much easier to understand and apply the protocols.” Peter also connects the Core Protocols to Google’s work:

Given the recent published studies from Google on successful teams (members are good at “social sensivity”) the next protocol level is like the perfect match: doing a Check-in by telling how you are actually feeling right now. You learn to acknowledge your self and you learn to accept that we have feelings and that we carry them with us in the meetings.

Thank you, Hannes and Peter! I am grateful you both for sharing your thoughts and for connecting this work with the Tuckman Model and Google's ideas on psychological safety. I notice that there’s a lot of research on team characteristics correlating to high performance, but there’s very little published on how teams can learn and embody these attributes. The Core Protocols are just the thing for teams that want high performance!

Experience Agile

Want your students or clients to really learn Agile? Then get them to teach Agile.

"Experience Agile" is the activity I use to close my my two-day Agile class. Students learn Agile by doing Agile and by teaching Agile to each other. The assignment:

Design, implement, and deliver courseware that teaches you everything you need to know about Agile.

The activity leads them through every step of the Agile product development life span, from product vision and team inception, through delivering the first version of their product. It works!

Download it here. Enjoy!

The Core Protocols: A Guide to Greatness

Introducing my book, The Core Protocols: A Guide to Greatness. Here’s the blurb:

Want to live in greatness? This book is your guide. The Core Protocols show you how to discover and obtain what you want, on your own, with your friends and family, and with the people you work with. Follow these easy recipes to understand and articulate your personal alignment, to connect and align with others, to share vision together, and to make the abundant goodness of the universe yours. Based on the work of Jim McCarthy and Michele McCarthy, this book is your concise guide to understanding what you want, connecting with others who support you, and living in greatness.

Here’s a review:

The Core Protocols are a life-changing experience in logical relationships and work. I use them all the time. I teach them. I share them. 

Destined to be a classic of intra and interpersonal interaction that is maybe slightly ahead of its time, those that embrace their simplicity reap massive rewards. 

I'm in.

Want a copy? You can buy it on Amazon.

Enjoy!

Manifesto for Greatness

On May 1, 2015, a group of 16 people gathered at Crystal Lake near Seattle, Washington. We announced to the world that we feel. That we suffer and that we are responsible. That we want a world filled with abundant love and greatness. That we have been "booted" running a new operating system, the code for abundant love and greatness.  That we want to infect the world with love and greatness at epidemic speed and force. That we are in. That we want your help.

We announced to the world what we want and who we are. We want abundant love and greatness in the world. We are the Greatness Guild.

This is our manifesto, a Manifesto for Greatness. We ask for help. Will you join us?

Manifesto for Greatness

We feel GLAD, SAD, MAD and AFRAID.

We have suffered mediocrity, broken promises, drama, selfishness and separation for too long. We are responsible for this mediocrity.

We observe that GREATNESS emanates from SELF-AWARENESS, FAITH, HOPE, PASSION, COURAGE, WISDOM, JOY, LOVE, INTEGRITY, VULNERABILITY, SAFETY and TRUST.

We have the tools – the CORE COMMITMENTS and CORE PROTOCOLS – that encode and deliver these virtues and ignite people to greatness.

We want the world to live in love and greatness.

WE ARE IN.

Will you join us?

Algimantas Stancelis, Alice Ivashina, Andrea Chiou, Axel Reed Dyksterhuis, Christian Délez, Christophe Thibaut, Dana Dyksterhuis, David Papini, Fazeel Gareeboo, Harold Shinsato, Josh Grob, Julia Ivashina, Richard Kasperowski, Sergej Koščejev, Stephen Hardy, Tolga Yazar

Read more about our efforts at greatnessguild.org.

Scaling Scrum: How To

Here’s a great Scrum scaling pattern based on the pattern that one of my clients uses. They use this pattern to scale their 500 people into a very successfully business unit of a huge technology company.

For each Product Backlog, there is one Product Owner (PO), one Scrum Master (SM), and up to four Development Teams. Each Development Team, plus the PO and SM, are a proper Scrum Team. The four Scrum Teams collaborate together on the single Product Backlog, ensuring that they are working on a single cohesive value stream.

Step 1: Form teams

The group’s manager creates a roster template on the wall. The roster template includes a column for each team and empty slots for team members. Rows indicate the desired mix of skills on each team: programmers, testers, UX specialists, DBAs, Op’s, etc.

Everyone in the group writes their name on a Post-It.

The manager explains the goal to the team. Group members fill the empty roster slots with their names. Talking and collaborating are encouraged! When all roster spots are filled, teams formation is complete.

Though not officially part of the scaling pattern, for great teams in just a few days, send them to a Core Protocols one-day workshop or five-day BootCamp.

Step 2: Scrum!

Here are recipes for your scaled Scrum events:

Sprint: All teams’ Sprints are synchronized, starting and ending at the same time.

Sprint Planning

Part 1—What: The whole group gathers in their shared work area. The PO re-acquaints the group with the contents of the Product Backlog. Each Development Team selects the subset of Product Backlog Items (PBIs) that they think they can get Done during the sprint.

Part 2—How: Each Development Team creates their individual Sprint Backlog. They carefully note dependencies and other collaboration needs with their cousin Dev Teams.

Part 3—Align: The whole group gathers again. Each Dev Team shares their Sprint Backlog with the group. Dev Teams share collaboration needs. They inspect and adapt, adjusting as needed. They agree on their Sprint Goal. (Did you notice the Diverge-Converge pattern? You'll see it again in the Daily Scrum and Sprint Retrospective.)

Daily Scrum

Each team holds its own Daily Scrum. Daily Scrums are staggered so the SM and PO can attend all of them.

Daily Scrum of Scrums: Representatives of each Dev Team meet to share their progress toward their individual and joint Sprint Goal. They inspect and adapt and adjust their plans.

Sprint Review

The group meets all together, along with stakeholders invited by the PO, for their Sprint Review.

Sprint Retrospective

Part 1—Teams: Each team holds their own Sprint Retrospective. They create a concrete plan to improve their team during the next sprint. They also identify ideas for improving the whole group. This meeting lasts about one hour.

Part 2—Group: The whole group meets to inspect and adapt as a team-of-teams. They create a concrete plan to improve the whole group during the next sprint.

Product Backlog Refinement

Refinement with volunteer leaders: The PO and volunteer leaders from the group meet to refine the Product Backlog regularly, usually 1-2 times per sprint. The purpose of this meeting is to get the backlog more Ready for the whole group, so we don’t waste people’s time with PBIs that aren’t Ready enough for the group to estimate together. For great collaboration, the size of this volunteer group is around 8 people. (“More than eight, no collaborate.” -Luke Hohmann) This subgroup may provide *initial* estimates for backlog items, to help the PO with initial forecasting. These estimates are not final, though, because estimating is the Development Team’s responsibility. Consider not sharing these estimates with the members of the Dev Team to prevent anchoring. Consider using this Product Backlog Refinement Workshop.

Refinement with whole group: The whole group convenes to refine the Product Backlog. The purpose of this meeting is to get the Product Backlog ready, with 1-2 sprints worth of PBIs totally Ready, and up to 6 months of backlog estimated—with the whole Development Team estimating backlog items together.

Scaling to 500 people

Each group is around 40 people. The pattern scales horizontally, up to 10 Product Backlogs and 40 Scrum Teams. For every five POs, there is a PO Manager. When there are two PO Managers, there is a PO Director above them.

Scrum Masters form a community of practice, perhaps with a manager handling their career development and HR needs. Programmers, testers, and other specialists do the same.

All together there are around 500 people in the business unit, including managers and support staff.